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FOREWORD 


Although written specifically for application to the Space Station Freedom Electrical Power 
System, the ETARA methodology and software can be applied in general to simulate 
Reliability, Availability, and Maintainability (RAM) characteristics of any system given a 
Reliability Block Diagram model of the system. 






iii 

PRECEDING PAGE BLANK NOT FILMED 


ACKNOWLEDGMENTS 


Acknowledgment is made to the following people for their contributions to the development 
of the ETARA methodology and software: 

Thomas Carr, Case Western Reserve University 
Jonathan Shiller, Case Western Reserve University 
Dale Stalnaker, NASA Lewis Research Center 
John Belt, United States Air Force Academy 


tv 


ETARA PC VERSION 3.3 

USER’S MANUAL 
CONTENTS 

1.0 Introduction 1 

2.0 Preparing the Input 1 

3.0 The ETARA Menus 4 

3.1 The ETARA MAIN MENU 4 

3.2 The SYSTEM DEFINITION Menu 6 

3.2.1 The DATA INPUT Menu 6 

3.2. 1.1 The BLOCK DATA INPUT Menu 7 

3.2. 1.1.1 Block Data by Type 7 

3.2. 1.1.2 Assignment of Block Numbers to Block Types 10 

3.2. 1.1.3 Block Ages at Beginning of Simulation 11 

3.2. 1.1.4 Block Installation Times 12 

3.2. 1.2 The RELIABILITY BLOCK DIAGRAM Menu 13 

3.2.1.2.1 Enter Reliability Block Diagram 13 

3.2. 1.2.2 Viewing the RBD 15 

3.2. 1.3 The SIMULATION PARAMETERS Menu 16 

3.2.1.3.1 Duration, Number of Runs, & Spare Resupply Intervals 16 

3.2. 1.3.2 Minimum Capacity for Reliability 18 

3.2. 1.3.3 Probability of Exceedence 19 

3.2.2 The SYSTEM FILE MANAGEMENT Menu 21 

3.3 The SIMULATION CONTROL Menu 22 


v 


3.4 The SIMULATION RESULTS ANALYSIS Menu 


24 


3.4.1 The AVAILABILITY RESULTS ANALYSIS Menu 25 

3.4. 1.1 System Availability Results 26 

3.4. 1.2 Block Availability 28 

3.4. 1.3 Continuous State Behavior 30 

3.4. 1.4 Probability of Exceedence 33 

3.4.2 RELIABILITY RESULTS 34 

3.4.3 MAINTAINABILITY RESULTS 35 

3.4.4 TIME CHECK 35 

3.4.5 The RESULT FILE MANAGEMENT Menu 36 

3.5 EXIT ETARA 36 

4.0 ETARA Algorithm Background 37 

4.1 Event Simulation 37 

4.2 Event Time Generation 39 

4.3 Collapsing the RBD 40 

APPENDIX A: An ETARA Application: “Duplicate Blocks” 42 

APPENDIX B: The Data Input Full Screen Editor 45 

APPENDIX C: Hardware and Software Requirements 

Installation and Execution Instructions 47 


APPENDIX X: An ETARA Example 


48 



1.0 Introduction 


ETARA (Event lime Availability Reliability Analysis) is an interactive, menu-driven 
reliability, availability and maintainability (RAM) simulation program. Given a Reliability 
Block Diagram representation of a system, ETARA simulates the behavior of the system over a 
specified period of time using Monte— Carlo methods to generate block failure and repair 
intervals as a function of exponential and/or Weibull distributions. Availability parameters 
such as equivalent availability, state availability (percentage of time at a particular output state 
capability), continuous state duration and number of state occurrences can be calculated. Initial 
spares allotment and spares replenishment on a resupply cycle can be simulated. The number of 
block failures are tabulated both individually and by block type, as well as total downtime, 
repair time, and time waiting for spares. Also, maintenance man-hours per year and system 
reliability, with or without repair, at or above a particular output capability can be calculated 
over a cumulative period of time or at specific points in time. 

The specific hardware and software requirements and installation instructions for ETARA are 
given in Appendix C on page 47. 

2.0 Preparing the Input 

A system can be represented by a reliability (or availability) block diagram (RBD). The RBD is 
a logical graphic illustration depicting the block configuration necessary for a function to be 
successfully accomplished. A block in the RBD can represent a component, a subsystem, or a 
system which performs a function that is either available or unavailable - there are no degraded 
modes of block performance. It is important to realize that the blocks do not have to be 
physically connected hardware in the actual system to be connected in the RBD. The criterion 
to remember when constructing an RBD is the block s role in contributing to an available 
system function. 

ETARA algorithms can model systems represented by an RBD which contains a combination 
of series, parallel, and M— of— N parallel blocks. When two blocks, A and B, are in series, it is 
equivalent to saying that block A and block B must be available for the subsystem to be 
available. When two blocks are in parallel, block A or block B must be available for the 
subsystem to be available. The situation where two blocks out of three blocks in parallel are 
needed for the subsystem to be available is termed “M— of— N parallel , in this case M=2 and 
N=3. A simple combination of two or more blocks that are either in series or parallel defines a 
simple subsystem. Subsystems can be combined further as series or parallel combinations of 
other subsystems and blocks. The complete system can then be defined as a combination of 
subsystems and blocks. 

There are no restrictions in ETARA on the number of total blocks in the RBD or on the number 
of blocks in a series, parallel, or M-of-N parallel subsystem. In addition, the same block can 
appear in more than one subsystem if such an arrangement is necessary to accurately model the 
system behavior. Although this is not allowed in deterministic RBD modeling, it is possible in 


1 


ETARA due to the fact that ETARA simulates failures and repairs of individual blocks and the 
way in which the subsystem RBD equations are solved. An example of this application is 
discussed in Appendix A. 

In order to facilitate data entry, it is advisable to annotate a copy of the RBD, prepared within the 
guidelines addressed in the previous section, as follows. The blocks of the RBD should be 
sequentially numbered starting at one. The proper designation of the blocks is the letter “B” 
followed by a number - Bl, B2, B3 etc. Subsystems are designated by an “S” followed by a 
number - SI, S2, S3 etc. The proper numbering of the subsystems is very important. The 
subsystems must be created from the “inside out”. A subsystem must not contain another 
subsystem of a higher number. For example, if subsystem Sx contains subsystems Sy and Sz, 
then x must be greater than both y and z. Beginning with the innermost set of blocks, each 
parallel or series set of blocks are partitioned into a subsystem which then can be placed in series 
or parallel with other blocks and subsystems. This process is repeated until the entire system is 
described by one “subsystem” which contains all other subsystems and blocks. Figure 1 shows 
an example of an RBD properly partitioned into subsystems. 
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Figure 1 - Example RBD of a Simple System 


The components or subsystems of the system are each represented by individual blocks in the 
RBD. Each block will be of a certain type. Each block type has associated data that 
differentiates it from other block types. The following data must be supplied for each block 
type: 
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capacity 

MTBF 


percentage of total system capacity 


Mean Time Between Failures, in years, for “random” 
failures. Exponential Distribution = exp(-t/MTBF) 

and/or 

Weibull shape factor and mean life, in years, from which the Weibull scale factor 

mean life is determined. 

Weibull Distribution = exp[-(t / scale) sha pe] 

mean time to repair, MTTR mean repair time, in hours 

number of initial local spares spares located ”on-site” 

number of initial depot spares remotely located spares 

The capacity of a block is the percentage of the total system capability that the block either 
produces, conducts, or supports. For the example of an electrical power system, the percentage 
of total power that can be produced by, is supported by, or is conducted through a block is 
defined as that block’s capacity. The two most important points to remember when determining 
a block’s capacity are that a block’s capacity is a percentage of the total system capacity and 
that support blocks which do not generate or contribute directly to the production of the output 
capability, but nevertheless are necessary in order for the system to operate, also have defined 
capacities. The capacities of these “support” blocks are proportional to the degradation of total 
system output capability when the block is unavailable. Or, as can frequently be the case, the 
support block can be assigned a capacity of 100% so as not to act as a bottleneck in the RBD. 

ETARA uses either, or both of the exponential and Weibull distribution functions to generate 
event times for a given block. The exponential function models the useful life period where 
items experience a constant hazard rate, 1/MTBF (i.e. random failures). The Weibull function 
can be used to model a wide variety of failure distributions. Two Weibull parameters, shape and 
scale, are adjusted to properly form the desired distribution. Please note that the definition ol 
“scale factor” as used in ETARA may differ from other commonly used definitions (the 
difference being: scaleETARA = scalet/shape). The third Weibull function parameter, the 
“location” factor, is used in ETARA to model the initial age or failure free period of an 
individual block at the beginning of the simulation and is described in detail in sections 
3.2. 1.1.3 and 4.2. 

Within ETARA, the mean life of a block type is specified along with the Weibull shape factor 
from which the Weibull scale factor is internally calculated from the equation, 

scale factor = mean life/Gamma( 1 + 1/shape factor) 

where “Gamma” denotes the Gamma function. If data for both distribution functions arc 
entered for a block type, ETARA generates time— to— failure from each function and uses the 
minimum of the two as the next failure event for a given block. 
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ETARA determines block down times based on the availability of local and depot spares, the 
MTTR, and the local and depot spares resupply interval. Local spares refers to the number of 
initial spares of that particular block type at the system location available for immediate 
replacement. Depot spares are remotely located from the system and are delivered to the system 
only during the local spare resupply intervals. The initial quantity of depot spares are 
replenished according to the depot spares replenishment interval. If a local spare is available 
when a block fails, ETARA uses only the block’s MTTR to determine when the block will next 
become available. If there are no local spares but there are depot spares of the failed block’s 
type, ETARA determines the down time to be the time remaining until the next local resupply 
action, plus the MTTR. If there is neither local nor depot spares of the failed block’s type, 
ETARA determines the down time to be the time to the earliest resupply interval after the depot 
spares stock has been replenished, plus the MTTR. 

3.0 The ETARA Menus 


The ETARA program is executed via a hierarchical set of menus which are described in the 
subsections that follow. The text in the shaded area in the box represents what appears on the 
monitor when running ETARA. The letters in parentheses on top of the boxes represent the 
keystroke sequence, beginning from the main menu, which will bring up the menu shown. In 
ETARA, each menu listing has one bold letter. When making a menu choice, simply press the 
key of the letter desired - there is no need to press [Enter]. The [Esc] key can be pressed to 
“escape” out of a currently displayed menu to the previous menu. ETARA has limited built-in 
error detection capability in that if a wrong or inappropriate key is pressed, an error message is 
flashed, a beep is sounded, and the user is returned to the same or higher-level menu. On-line 
help screens can be accessed by pressing the [FI] key. 

3.1 The ETARA MAIN MENU 

On entering the ETARA program, the following introduction is briefly flashed, 
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followed by the ETARA Main Menu 


ETARA MAIN MENU 

Information . 

System definition ifj|| 
Run simulation ] | 
Analyze results . t;-'- : 
eXit ETARA 


The ETARA main menu displays the basic steps used to approach and solve a problem. 
Selection S brings up a menu which allows the user to enter or modify the information necessary 
to perform a simulation of a system and manage (e.g. save, load, and delete) the system data in 
terms of system configuration files. Selection R brings up a menu which enables the user to 
choose an availability, reliability (with or without repair), or maintainability simulation either 
interactively or in batch mode. Selection A brings up the analytical results menu from which 
the results can be displayed, printed, and managed. Selection X is used to exit ETARA. 
Selection I displays the information contained in the Introduction to this manual, section 1.0. 
Remember, to make a selection simply press the key of the letter desired (without pressing 

[Enter]). 
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3.2 The SYSTEM DEFINITION Menu 

Keystroke: (S) 


SYSTEM PEPiKITlON 
Enter or modify data ' 
File management 
eXtt 


The SYSTEM DEFINITION Menu allows the user to enter or modify the input necessary to 
perform a simulation of a system, and manage (e.g. save, load, and delete) the system data in 
terms of system configuration files. 

RAM simulations are performed on specific “systems” or equivalently, “system 
configurations.” For this reason, ETARA stores each system in a separate file which can be 
saved, deleted, reloaded and edited. A new system must be defined and saved in ETARA via the 
SYSTEM DEFINITION Menu. A new system configuration file must be saved using this menu 
before exiting ETARA or it will be lost (see section 3.5 for safeguards). Saved systems can be 
reloaded for use in a simulation or for editing. 

Selection X will return the user to the ETARA MAIN MENU (3.1). 

3.2.1 The DATA INPUT Menu 

Keystrokes: (S) (E) 


- j DATA INPUT I \ 

Block data, numbers, initial ages and installation times 
Reliability block diagram' - / ■ 

Parameters of the simulation 
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In order to perform a RAM simulation, each option on this menu must be selected and the 
appropriate input given. Selection B allows the user to define the RAM parameters for each 
block type, assign individual blocks to the various block types, and define the initial ages and 
points in time when blocks are installed in the system. Selection R allows the user to build a 
Reliability Block Diagram (RBD) via a full screen editor. Selection P allows the user to define 
the parameters that govern a system simulation . 

As an example, input for a new system represented by the RBD depicted in figure 1 is illustrated 
in Appendix X. 

Selection X will return the user to the SYSTEM DEFINITION Menu (3.2). 


3.2.1.1 The BLOCK DATA INPUT Menu 

Keystrokes: (S) (E) (B) 


BLOCK DATA INPUT 
Data by type ' 

Numbers for each typfc'^SIll 
Ages at beginning of sitnnjaiion 
Insolation i 

eXit 


Selection D is used to define the block data input to ETARA for each unique type of block. 
Selection N is used to identify the block numbers of blocks in an RBD to a unique block type. 
Selection A is used to assign initial ages to blocks which experience wear out. Selection I is 
used to assign installation times to blocks which are not initially part of a system at the 
beginning of a simulation. Selection X will return the user to the DATA INPUT Menu (3.2. 1). 

3.2. 1.1. 1 Block Data by Type 

Keystrokes: (S) (E) (B) (D) 



Capacity 

<*)'.=.;• 

MTBF, Yrs 

Mean Life, Yrs : 
:|:(Wearput) §§§ 

hrs. 

Shape 

Factor 

Spafds : 

Depot 

Spares, 

' ‘ • • • : . Y;' v !\f : 

TYPE I 

If toe f 

; v 

•v-5 

'i 1 1 


flffj 

9999 
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After selecting the ’’Data by type” choice from the BLOCK DATA INPUT menu, ETARA 
displays a table with the above listed column headings with full screen editing capability. The 
information given under the column headings illustrated above are default values used by 
ETARA. As described in 2.0 Preparing the Input, the components or subsystems of a system arc 
each represented by individual blocks in the RBD. Each block will be of a certain type. Each 
unique block type has associated data that differentiates it from other block types. The block 
data input is defined with respect to each unique type of block. For example, an RBD may 
contain 100 identical blocks in series. In this case, there is only one unique type of block so that 
the user would enter data for only this one type of block. 

The full screen editor has a vertical black column under each heading surrounded by a border. 
The data for each type of block is defined horizontally, with the black spaces being the 
“window” for the alphanumeric input. For example, the black window for the block type 
’’Name” column is 10 spaces wide, allowing for a block name, abbreviation or acronym of 10 
alphanumeric characters. The name can also contain spaces (which will appear as underscores 
on the printout). The numeric data can be either integer or real. 

To move from one window to the next, use the [Tab] key to move right and the [Shift] [Tab] 
keys to move left. The right and left arrow keys can also be used. The up and down arrow keys 
are used to move in those respective directions. If the block data input fills the screen, the [Pg 
Dn] key is used to page down the screen to obtain more space. The [Pg Up] key will page up the 
screen. 

The block data editor can be used to edit existing data as well as define new data. If on entering 
the editor to define new block data there is already data existing in the table, the user can type 
over the existing information, or “mark” the data and delete it. The editor has on-line help 
screens which can be accessed by pressing the [FI] key. Complete instructions for using the full 
screen editor appear in Appendix B. 

The appropriate procedure for completing the Block Data table is to begin in the upper left with 
a block type Name. The user can then proceed horizontally with the block capacity and other 
data or proceed vertically with the next block type Name. Complete data must be supplied for 
each block type: there can be no blanks in any of the data columns. As previously described in 
2.0, the capacity of a block is the percentage of the total system capability that the block either 
produces, conducts, or supports. For the example of an electrical power system, the percentage 
of total power that can be produced by, is supported by, or is conducted through a block is 
defined as that block’s capacity. It is not critical to determine the individual block capacities for 
blocks in an M-of-N parallel arrangement since the M-of-N subsystem capacity definition 
will override the individual block capacities (see 3.2.1. 2.1). However, since the Capacity entry 
can not be left blank for these blocks, a “dummy” capacity must be defined. 

The two most important points to remember when determining a block’s capacity arc that a 
block’s capacity is a percentage of the total system capacity and that support blocks which do 
not generate or contribute directly to the production of the output capability, but nevertheless 
are necessary in order for the system to operate, also have defined capacities. The capacities of 
these “support” blocks can be proportional to the degradation of total system output capability 


8 



when the block is unavailable. Or, as can frequently be the case, the support block can be 
assigned a capacity of 100% so as not to act as a bottleneck in the RBD. 

ETARA uses either, or both of the exponential and Weibull distribution functions to generate 
event times for a given block. The exponential function models the useful life period where 
items experience a constant hazard rate, 1/MTBF (i.e. random failures). The MTBF for use in 
the exponential distribution function is entered in the column under the “MTBF, Yrs 
(Random)” heading. The Weibull function can be used to model a wide variety of failure 
distributions. Two Weibull parameters, shape and scale, are adjusted to properly form the 
desired distribution. Within ETARA, the mean life of a block type is specified along with the 
Weibull shape factor from which the Weibull scale factor is internally calculated from the 
equation, 


scale factor = mean life/Gamma(l+l/shape factor) 
where “Gamma” denotes the Gamma function. 

If data for both exponential and Weibull distribution functions are entered for a block type, 
ETARA generates time-to-failure from each function and uses the minimum of the two as the 
next failure event for a given block. To use only the exponential distribution function, a 
“99999” j s entered for Mean Life, while ”99999” is entered for the MTBF if only the Weibull 
function is to be used. 

The time— to— repair for a given block is calculated with the block’s MTTR and the Weibull 
distribution function with the shape factor set to 3.44, approximating a normally distributed 
repair time. The full repair time for a block is also dependent on the logistics delay time which 
depends on the number and location of spares. 

ETARA determines block down times based on the availability of local and depot spares, the 
MTTR , and the local and depot spares resupply interval (see 3.2.1. 3.1). Local spares refers to 
the number of initial spares of that particular block type at the system location available for 
immediate replacement. Depot spares are remotely located from the system and are delivered 
to the system only during the local spare resupply intervals. The initial quantity of depot spares 
are replenished according to the depot spares replenishment interval. If a local spare is 
available when a block fails, ETARA uses only the block’s MTTR to determine when the block 
will next become available. If there are no local spares but there are depot spares of the failed 
block’s type, ETARA determines the down time to be the time remaining until the next local 
resupply action, plus the MTTR. If there is neither local nor depot spares of the failed block s 
type, ETARA determines the down time to be the time to the earliest resupply interval after the 
depot spares stock has been replenished, plus the MTTR. There is one further condition on the 
spares resupply action, the ’’cutoff’ , described in detail in 3.2. 1.3.1. 

Pressing [Enter] will complete the block type definition, save the data and return the user to the 
BLOCK DATA INPUT menu (3.2.1.1). Pressing [Esc] will allow the user to leave the editor 
without saving changes. 
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3.2. 1.1.2 Assignment of Block Numbers to Block Types 

Keystrokes: (S) (E) (B) (N) 



This selection is used to match the block numbers (i.e., the individual block identifier number, 
or digit) in the RBD to a unique type of block defined in the Block Data table described in the 
previous section. On this screen, data is also entered via a full screen editor, with identical 
capabilities as the Block Data editor described in the previous section - see appendix B for 
complete instructions. There are two headings in this editor as indicated in the example above. 
ETARA automatically displays the block “Type” from the type names defined in the Block 
Data table editor described in the previous section. In the above illustration, ETARA has 
displayed the default type name “Typel”. For each block type listed, the user needs to define 
the individual block numbers which are of this type. Integer block numbers are entered which 
are of the block type listed on the same line to the left under the “Type” heading. Remember, a 
block number can be assigned to only one type of block. Numbers in a sequence can be input 
with the beginning number, a “dash” [-], and the ending number. For example, [12 4-7 9 
1 1-25] is an appropriate response. 

The [Tab] key is used to move the cursor to the right or down while the [Shift] [Tab] keys will 
move the cursor to the left or up. If more than one line is needed to define block numbers for a 
given block type, a blank line can be inserted by pressing the [F8] key while the cursor is 
positioned one line below the line of the block type which is to be continued. The editor will 
then prompt the user for the number of rows to insert. With the user response of one, a blank line 
will then appear above the cursor, without the block type name, in which the block number input 
can be continued. The Block Number editor has limited built-in error checking which will 
notify the user with a beep and a brief message when a block number is used more than once or 
is missing. 

Once the block numbers have been correctly defined, the [Enter] key is pressed, the data is 
saved and ETARA returns to the BLOCK DATA INPUT Menu (3.2.1. 1). Pressing [Esc] will 
allow the user to leave the editor without saving changes. 
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3.2.1.1.3 Block Ages at Beginning of Simulation 

Keystrokes: (S) (E) (B) (A) 


••• 

i PJock; Jtffopbefs 

ill iiiiiii 

| MMMBI • . ' || 


This selection is used to assign initial ages to blocks which will either experience aging and 
eventual wearout, or have an initial “failure free” period. The initial block age parameter is only 
used in conjunction with the Weibull distribution and is equivalent to the Weibull “location” 
parameter. 

At the beginning of the simulation, it may happen that some of the blocks which experience 
aging are not "brand new” and have already accumulated some “initial” age. This initial age is 
subtracted from the time to first failure determined with the Weibull distribution function 
(which is being used to model the increase in failures with time, i.e. wearout) so that the age of a 
block prior to the beginning of the simulation is properly accounted for. 

Alternatively, a block may experience a “failure free” period at the beginning of the simulation. 
In this case, a ne gative number corresponding to the failure free period, in years, is entered. 
During the simulation, the defined failure free period is added to the time to first failure 
determined with the Weibull function so that the initial period during which the block will 
experience no failures related to the Weibull distribution is properly accounted for. 

This screen is also a full screen editor identical to the Block Data and Block Number editors 
previously described. The example above shows the default values assumed by ETARA - an 
initial age of 0 years for block 1. If no blocks have an initial age (or failure free period), the user 
should press [Enter] to continue to the next menu. ETARA will internally assign an initial age 
of zero for every block in the system. If there are blocks which have an initial age or failure free 
period, the age, in years, is entered in the first column, “ Age, Yrs ”. As indicated above, a 
positive entry corresponds to an initial age due to prior wear while a negative entry corresponds 
to an initial failure free period. The [Tab] key is used to move the cursor to the right to the 
“Block Numbers” column and the integer block numbers which are of that age are entered. 
Pressing the [Shift] and [Tab] keys together will move the cursor to the left. If more than one 
line is needed for a given age, simply type the same age in the next row of the first column and 
continue entering the block numbers. See the previous section and Appendix B for more 
complete instructions on the use of the full screen editor. Only blocks with an initial age or 
failure free period need to be identified with this selection. If a block number does not have an 
initial age or failure free period assigned to it by the user, ETARA assumes a value of zero. 
Pressing [Enter] will complete the block ages definition, save the data and return the user to the 
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BLOCK DATA INPUT menu (3.2.1. 1). Pressing [Esc] will allow the user to leave the editor 
without saving changes. 


3.2.1.1.4 Block Installation Times 

Keystrokes: (S) (E) (B) (I) 


K Install. [ 
11 Tinie. vL 1 

r |lock ifnrnbers 

| Jjg m 

s * ... " ' s v . w % . ' \ ^ 

^ v ' ■' *• ^ •- 


This option is used to assign installation times to blocks that are not initially installed, that is, not 
present at the beginning of the simulation. A system may be constructed in stages, with not all 
of the blocks operating at the start of the simulation. To account for this, an installation time, in 
years, may be entered. The complete block diagram should still be entered first. The 
non-installed blocks will be assigned a capacity of zero and will not contribute to the capacity 
of the system until their installation time is reached during a simulation. No time for first failure 
will be calculated for these blocks until they are installed. Before all blocks are installed, the 
system’s maximum capacity will usually be less than 100%. In ETARA, availability results 
are normalized to the maximum possible output capacity during a given time period. This 
means that during the period when blocks are being installed, occurrence of the maximum 
capacity state possible, even though it could be less than the 100% ultimately possible, will be 
bookept under the 100% capacity state. In the availability results displays, the 100% capacity 
state availability includes occurrences of any state which was the maximum possibly state 
during a given time period. 

This screen is again a full screen editor identical to the editors previously described. The 
example above shows the default values assumed by ETARA - an installation time of year 0 for 
block 1. If no blocks have a ’’delayed” installation time, the user should press [Enter] to 
continue to the next menu. ETARA will internally assign an installation time of zero for every 
block in the system, effectively activating the entire system at the beginning of the simulation. 
If there are blocks which are not initially installed, the installation time, in years, is entered in 
the first column, “ Install. Time, yr”. The [Tab] key is used to move the cursor to the right to the 
“Block Numbers” column and the integer block numbers which are to be installed at that time 
are entered. Pressing the [Shift] and [Tab] keys together will move the cursor to the left. If more 
than one line is needed for a given age, simply type the same installation time in the next row of 
the first column and continue entering the block numbers. See appendix B for more complete 
instructions on the use of the full screen editor. Pressing [Enter] will complete the installation 
time definition, save the data and return the user to the BLOCK DATA INPUT menu (3.2.1. 1). 
Pressing [Esc] will allow the user to leave the editor without saving changes. 
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3.2.1.2 The RELIABILITY BLOCK DIAGRAM Menu 

Keystrokes: (S) (E) (R) 



reliability block diapitmi 1 
. Graphic layout display 
eXU 


Selection E is used to enter or modify an RBD. Selection G is used to graphically display the 
RBD. Selection X will return the user to the DATA INPUT Menu (3.2.1). 

3.2. 1.2.1 Enter Reliability Block Diagram 

Keystrokes: (S) (E) (R) (E) 


Sub# 

jiJiype.: 

Elements .. 1 . 

Mof 

M Data t: 
. : ;&bacfty r 


311! 

bll 




After selecting E from the previous menu, ETARA displays the above illustrated table with full 
screen editing capability. The entries shown above under the ”Sub #”, ’’Type”, and ’ Elements 
headings are the default assumptions. When entering data into this table, it is highly 
recommended that the user have on hand the annotated RBD as described in section 2.0 
Preparing the Input. 

The full screen editor has a vertical black column under each heading surrounded by a border. 
The data for each subsystem is defined horizontally, with the black spaces being the “window 
for the alphanumeric input. For example, the black window for the subsystem number column 
is 4 spaces wide, allowing for a subsystem number 4 digits long. 

To move from one window to the next, use the [Tab] key to move right and the [Shift] [Tab] 
keys to move left. The right and left arrow keys can also be used. The up and down arrow keys 
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are used to move in those respective directions. If the block data input fills the screen, the [Pg 
Dn] key is used to page down the screen to obtain more space. The [Pg Up] key will page up the 
screen. The [Enter] key will terminate the full screen editor and return to the RELIABILITY 
BLOCK DIAGRAM Menu (3.2. 1.2). 

The RBD table editor can be used to edit existing data as well as define new data. The user can 
simply type over the default data or “mark” any existing data and delete it. The editor has 
on-line help screens which can be accessed by pressing the [FI] key. Complete instructions for 
using the full screen editor appear in Appendix B. 

The appropriate procedure for completing the Reliability Block Data table is to begin in the 
upper left with a subsystem number. The user can then proceed horizontally with the subsystem 
type and other data or proceed vertically with the next subsystem number. Under the ”Sub #” 
column heading, the user enters the integer corresponding to the subsystem number in the RBD. 
Under the ”Type” column heading, the user enters the first letter of the type of subsystem; 
series, parallel, and M-of-N parallel, either variable or binary. If a parallel subsystem is an 
M-of-N Parallel arrangement, the ”Min #” and ’’Capacity” columns under the ”M of N Data” 
heading must be filled out as described below. As first described insection 2.0, when two blocks 
A and B are in series, it is equivalent to saying that block A and block B must be available for 
the subsystem to be available. When two blocks are in parallel, block A or block B must be 
available for the subsystem to be available. The situation where two blocks out of three blocks 
in parallel are needed for the subsystem to be available is termed “M-of-N parallel”, in this case 
M=2 and N=3. M-of-N subsystems can comprise only blocks; no subsystems can be in an 
m-of-n parallel arrangement. However, there is no limit on the number of blocks in any type 
of subsystem, or the number of subsystems contained in any of the possible subsystem types, 
except M-of-N as just mentioned. 

After the subsystem type selection is made (series, parallel, or M-of-N ), the actual blocks 
and/or subsystems contained in that subsystem must be entered in the column labeled 
“Elements”. The appropriate format for the response is to precede the block numbers in the 
subsystem with the letter “b” and precede the subsystem numbers contained in this particular 
subsystem with an “s”. A space is not required between the “b” or “s” and the block or 
subsystem numbers. Numbers in a sequence such as [b 5 6 7 8] can be input with the beginning 
number, a “dash” [-], and the ending number [b 5-8]. Any combination of the above is allowed. 
Examples of allowed format for a subsystem are, 

1) b 1 2 5-8 10 12-25 s 1 2 3-5 

2) b2 s3 4 

3) s 1 b 1 

4) b3 4 5 

It is important to remember that in subsystems which contain both blocks and other subsystems 
to delineate the blocks by a “b” followed by the block numbers and delineate subsystems with 
an “s” followed by the subsystem numbers. 


14 



When a subsystem type is a binary or variable M-of-N parallel, the last two columns of the 
editor under the ”M of N Data” heading must be used to define the required further information. 
The column labeled “Min #” is the “M” in the M-of-N statement. That is, the number of blocks 
that need to be available so that the entire parallel arrangement of N blocks can be considered 
available. The distinction between binary and variable M-of— N subsystems is important in 
determining the capacity of the M-of-N subsystem. When binary M-of-N is desired, a b is 
entered in the ’Type” column and a single capacity must be entered under the “Capacity” 
column heading. A binary M-of-N subsystem is available at this user-defined capacity when 
M or more blocks are available. When less than M blocks are available, the binary M-of-N 
subsystem is considered unavailable (zero output capacity). 

When a variable M— of N is desired, a v is entered in the "Type” column and a set of capacities 
must be entered under the “Capacity” column heading. A variable M— of— N subsystem is 
available at the first user-defined capacity in this set when M or more blocks are available. The 
subsystem is available at the second user-defined capacity when exactly (M-l) blocks are 
available, and so on down to the last capacity in the set which occurs when exactly 1 block is 
available. When none of the blocks are available, the variable M-of-N subsystem is considered 
unavailable (zero output capacity). The set should contain exactly M number of capacities. 
The variable M-of-N subsystem allows greater flexibility in how an M-of-N parallel 
arrangement of blocks may degrade in terms of output capacity. The capacity defined here for 
an M— of— N subsystem will override the capacities of the individual blocks contained in this 
type of subsystem (see 3. 2. 1.1.1). 

Pressing [Enter] will complete the RBD definition, save the data and return the user to the 
RELIABILITY BLOCK DIAGRAM menu (3.2. 1.2). Pressing [Esc] will allow the user to 
leave the editor without saving changes. 


3.2.1.2.2 Viewing the RBD 

Keystrokes: (S) (E) (R) (G) 

This selection is used to graphically display an RBD which has just been defined after working 
through the RBD table editor (3.2.1.2.1) or which has been reloaded from a saved system 
configuration file. The block number, type name, and installation time are displayed within 
each block of the RBD. The cursor keys, and the [Pg Dn], [Pg Up], [Home], and [End] keys 
may be used to move around the display. The viewing location in the diagram is displayed at the 
bottom of the screen. 

Pressing [Enter] will return the user to the RELIABILITY BLOCK DIAGRAM Menu 
(3.2. 1.2). 
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3.2.1.3 The SIMULATION PARAMETERS Menu 

Keystrokes: (S) (E) (P) 


mmuSm parameters 1 ' 

a a - 

Duration, number of runs, spares resupply 
Minimum capacity for reliability 
Probability of exceed encl ’ ' " 
exit 


This menu is used to define the data necessary to perform a simulation. Selection D allows the 
user to define the ’’duration”, or length of time over which a system’s behavior will he 
simulated, the ’’number of runs” or number of times that the duration will be repeated to build 
meaningful statistics, and the local and depot spares replenishment intervals. The M and P 
selections allow the user to define criterion for reliability analyses. 


3.2.1.3.1 Duration, Number of Runs, & Spare Resupply 
Intervals 

Keystrokes: (S) (E) (P) (D) 



1 





Duration 


llflflars)' Il§§ 



Number of Runs 

■ i 




Local Spates Replenishment Interval | 

'■ W£l 

- (Days) 



Resupply Cutoff 


1 (Days) || 



Depot Spares Replenishment Interval § 

Mi_ 

_ (Days) 








This is a field editor that allows the user to enter five parameters governing a simulation. 
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In the first field, the user enters the duration - the number of years of system operation which 
will be simulated. ETARA assumes the system begins the simulation operating at 100% output 
capability with no failed blocks. 

The next field deals with the number of simulations, or “runs of the system over the given 
duration. There is no limit on the number of runs, except for the user s patience in waiting for 
the output. Longer run times will result as more events occur for a simulation, caused by many 
blocks and/or many failures and repairs, and the number of simulation runs performed. As one 
indication of the time involved in completing a series of simulation runs, the 10 availability 
simulation runs of a 30 year duration for the 10 block system illustrated in appendix X took 2 
minutes and 23 seconds on a Dell 386 PC at 20 Mhz with a math co— processor (see 3.3 and 
Appendix X). 

The final three fields deal with spares resupply. As mentioned in 2.0 and 3.2.1. 1.1, ETARA 
determines block down times based on the availability of local and depot spares, the MTTR , 
and the local and depot spares resupply interval (see 3.2.1.3.1). Local spares refers to the 
number of initial spares of that particular block type at the system location available for 
immediate replacement. Depot spares are remotely located from the system and are delivered 
to the system only during the local spare resupply intervals. The initial quantity of depot spares 
are replenished according to the depot spares replenishment interval. If a local spare is 
available when a block fails, ETARA use only the block’s MTTR to determine when the block 
will next become available. If there are no local spares but there are depot spares of the failed 
block’s type, ETARA determines the down time to be the time remaining until the next local 
resupply action, plus the MTTR. If there is neither local nor depot spares of the failed block s 
type, ETARA determines the down time to be the time to the earliest resupply interval after the 
depot spares stock has been replenished, plus the MTTR. 

Given the above discussion, it is seen that after the supply of local spares of a given block type 
runs out and depot spares are still available, the system would then receive spares from the depot 
according to the ’’Local Spares Replenishment Interval”, subject to the cutoff condition 
described below. Note that the local spares quantities are NOT restocked. The local spares 
replenishment interval dictates when spare blocks are shipped from the depot to replace a failed 
block. The local spares replenishment interval is entered in the third field of this editor and must 
be an integer or real number > 0. 

A condition on the local spares replenishment interval, indicated by the fourth field in this 
editor, is the “Resupply Cutoff’. The “cutoff’ time (in days) is used to represent the finite time 
before a scheduled resupply action necessary to manifest and load spares on the resupply 
vehicle. For example, suppose the system under consideration is a space station in low earth 
orbit and the resupply vehicle is a space shuttle. Assume further that the shuttle visits the space 
station every 90 days to replenish the station’s supplies and bring spare parts. Finally, assume 
that if a failure occurs on the space station, a spare part can be ordered from the earth and 
brought to the station with the next shuttle resupply visit. However, if a space station part fails 
30 days or less from the next scheduled resupply visit, there will not be enough time to manifest 
and load a spare part on the shuttle. This scenario can be modeled in ETARA by assigning the 
“spares replenishment interval” a value of 90 days with a “cutoff time” of 30 days. This means 
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that depending on when a part fails, a spare can be brought up to the station in as little as 30 days 
(failure occurred just before the cutoff time) or as late as 120 days (failure occurred just after the 
cutoff time so spare delivery had to wait until the following resupply visit). Allowable values 
for the cutoff time are (0 < cutoff time < replenishment interval). 


The final field in this table is the ’’Depot Spares Replenishment Interval”. The depot spares 
replenishment interval refers to the number of days between the restocking of original number 
of depot spares. If a system requires depot spares, ETARA executes as explained above and 
decrements the number of depot spares for the failed block type. The depot spare replenishment 
interval must be an integer or real number > 0. 

Each of these prompts have default responses as shown above which the user can type over. 

3.2.1.3.2 Minimum Capacity for Reliability 

Keystrokes: (S) (E) (P) (M) 



Minimum 


: Caoacitv 

lllil 

100 

1 m 

$0 


This selection is a full screen editor which allows the user to define a ’’minimum capacity” of 
the output of a system which is only used by ETARA as a success criterion when performing 
reliability simulations. In ETARA, the reliability (with or without repair) of a system to operate 
at or above this user-defined minimum capacity is calculated (see 3.3). 

In this editor, the user defines the points in time under the ’’Year” column heading to which 
a”minimum capacity” threshold will be assigned as the system’s success criterion for a 
reliability simulation. The points in time, given in years, signify the point during a system’s 
simulation at which the corresponding minimum capacity threshold, in percent of the total 
system capacity, takes effect. In the example illustrated above, ETARA will assign success 
criterion from the beginning of the simulation (year 0) to year 1 of a minimum of 100% system 
capacity followed by a minimum of 50% system capacity from year 1 to the remainder of the 
duration. In a individual run during a reliability simulation, if failures within a system results 
in a system capacity below the minimum capacity at any time, even if only briefly, the particular 
simulation run is stopped, the violation of the success criterion noted, and a new simulation is 
begun. See 3.4.2 for explanation of the reliability results for this particular option. 

If no information is entered by the user, ETARA will default the minimum capacity 
requirement to zero for the entire duration of a system.The full screen editor for this section is 
identical to the editors previously described. See appendix B for more complete instructions. 
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3.2.1.3.3 Probability of Exceedence 

Keystrokes: (S) (E) (P) (P) 


|IMBBSS5S^a5S5S 

...-I.;.*- 

•\.V. fvjfifl Profile eipachy date v. !• ; 
f '^|1| Multiple capacity level data 



This selection is a full screen editor which allows the user to define probability of exceedence 
parameters. As the phrase implies, probability of exceedence refers to the probability that, at 
user-specified points in time, a system’s capacity will exceed user-specified output capacity 
thresholds. The user is given the choice of two types of probability of exceedence setups. 

The first option, selection P, allows the user to define a capacity profile as a function of time. 
This is equivalent to a load profile or power demand curve in electrical power system analyses. 
Data is entered as points-in-time (yrs)/capacity level (%) pairs representing points along a 
capacity profile. It is important that capacity profile data be entered in pairs, with a capacity 
level corresponding to each point— in— time, in years, so the number of periods and capacity 
levels should be equal. In the example illustrated below, the user has specified a 75% capacity 
level from year 0 to year 1, followed by a 50% capacity level from year 1 to year 2, followed by 
an increase back to 75% at year 2. Through a number of simulation runs, ETARA will evaluate 
the probability that the user-defined capacity profile will be met or exceeded. See 3.4. 1.4 for 
discussion of the results. 

Keystrokes: (S) (E) (P) (P)(P) 


Probability of Exceedence Data 

Time, 

\M . Capacity : " . ' : 


■£;, levels -C . 

. 0 

Mis M ' 


" mm 

2 . 

■ . -1$ r- • 


The other option available to the user, through selection M from the ’’Probability of 
Exceedence” menu, is to enter a set of points-in-time and a set of capacity levels independent 
of one another. During a simulation, ETARA will take a “snap shot” of the capacity of the 
system at each user-specified point-in-time to see if it meets or exceeds the set of 
user— specified capacities. This data is used to generate a type of instantaneous availability 
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matrix which gives the probability that the system operated at or above the user-specified 
capacity levels at the user-specified points-in-time. See 3.4.1.4 for further discussion of the 
results. 


If the user wishes to enter the points-in-time or capacity levels as a sequence with regular 
intervals, the set can be input with the beginning number, a “dash” [-], the ending number, a 
“comma” [,], and the interval. 


For example: 


Keystrokes: (S) (E) (P) (P)(M) 


probability o 
Time, yrs : 

f Exceedence Data 
"Capacity-' 
j .levels 

0 

l-2,.25 

■ irzi-jrm:'. 1 

0-50, 10 


is equivalent to: 


Probability o 
Time, yrs. 

f Exceedence Data 
Capacity 
. levels 

0 .... i 

1 

1.25 ... 
:■ i.$o II 

• . 1.75 J 

:.. 2 ' 

3 . 

0 

10 

20 

' 30 •' •••■ 

40 : 

50 


In the example illustrated above, at each point-in-time given in the left column, ETARA will 
evaluate the probability of exceeding each of the capacity levels in the right column. 

The full screen editor for this section is identical to the editors described previously. See 
appendix B for more complete instructions. 
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3.2.2 The SYSTEM FILE MANAGEMENT Menu 

Keystrokes: (S) (F) 


: syst^Sjb management ' 

-."7 • L^jj^uYiTixmTnTiiiii m ' - ~ - ~ 

Load a previously saved system 
Save the present system 
Delete a System jf§ 

Rename a system 

' ; ;i^iv ! : : ' •: i v=:i : : i i ! : - i. 


The SYSTEM FILE MANAGEMENT menu is used to Load, Save, Rename and Delete system 
configuration files. The system configuration files contain all the information from the DATA 
INPUT Menu (3.2.1); the system’s RBD, block data, numbers, and initial ages, installation 
times, parameters of the simulation and the spare resupply interval data. This information is all 
that is necessary to perform RAM simulations. 

On selection of choices L and D, ETARA will respond by listing the extended filenames of 
previously stored systems in reverse chronological order according to the times they were 
saved. The size, date ,and time saved are displayed along with the names. For those files that 
have not been assigned extended names, the DOS file names will be displayed. The user selects 
a file with the up and down cursor keys, and presses [Enter] when the desired file is highlighted. 
For options L and D, the file will be loaded or deleted, respectively. 

On selection of choice R, ETARA will display the list of filenames from which the user can 
choose as described above. The user is then prompted for a new extended file name. The name 
can be made up of any alphanumeric characters, however, the first character must be a letter. 
In the case of files that do not have extended names, this rename procedure will create one for 
them. 

Similarly, selection of S will display the filename list and immediately prompt the user for an 
extended name for the system to be saved. The displayed filename list should enable the user to 
create a name for the new file to sufficiently describe it and differentiate it from the others. As 
stated above, the name can be made up of any alphanumeric characters, with the exception that 
the first character must be a letter. 

Upon completion of any of these selections, ETARA returns to the SYSTEM DEFINITION 
Menu (3.2). 
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If the user chooses NOT to load, save, rename, or delete a system from the stored systems list, 
the [Escape] key can be pressed. ETARA will then sound a “beep”, flash a message and return 
the user to the SYSTEM DEFINITION Menu (3.2). 

3-3 The SIMULATION CONTROL Menu 

Keystroke: (R) 


SIMULATION CONTROL 

Availability ' . ■ 

Reliability with repair 
reliability, No repair • 
Maintainability 
Batch mode 
eXit ••• > .. 


Selecting the ’’Run simulation” option from the ETARA MAIN MENU brings up the 
’’SIMULATION CONTROL” menu. This menu allows the user to choose from Availability, 
Reliability with repair, reliability with No repair, and Maintainability simulations, as well as a 
multiple run Batch mode. ETARA immediately begins the simulation when a key is pressed, 
given that the user has reloaded a saved system configuration file or has just finished defining a 
new system. eXit will return the user to the ETARA MAIN MENU (3.1). 

The Availability simulation is carried out assuming that the system is operating at 100% output 
capability with no failed blocks at the beginning of the simulation. The system’s block failures 
and repairs constitutes the events during a simulation. Block time— to— failure and 
time-to-repair are determined via Monte-Carlo methods using the user-defined reliability 
(exponential MTBF and/or the Weibull shape and scale factors — see 3. 2. 1.1.1) and 
maintainability (MU R, spares replenishment interval and cutoff time — see both 3.2.1. 1.1 and 
3.2. 1.3.1) data, respectively. At each event, ETARA solves the the reliability block diagram to 
determine the output capacity of the system, i.e., its capacity state. The simulation is performed 
for the specified system lifetime or duration (see 3. 2.1. 3.1). ETARA has completed a single 
simulation “run” when the end of one duration is reached. ETARA then resets the system to its 
initial state and repeats the simulation for another duration. This process is repeated until the 
user-specified number of runs is reached. The probability of exceedence statistics are also 
accrued during an Availability simulation. 

The same basic process described above is used when performing the Reliability simulations. 
The difference is that when a block failure causes the system’s output to fall below a 


22 


user-specified minimum output capacity (see 3.2. 1.3.2), the current simulation run is 
terminated and a new run is initiated. A run is successful if it reaches the duration of the 
simulation without falling below the minimum capacity. The system’s reliability at or above 
the specified minimum capacity over the given time period (duration) is calculated as the ratio 
of the number of successful runs to the total number of runs (maximum runs) attempted. The 
’’Reliability with repair” option proceeds in the manner of the Availability simulation with the 
additional conditions just described. For the ’’reliability. No repair” option, all block MTTRs 
are set to a very large number to ensure that no failed block returns to service. 

During a Maintainability simulation, only failures and repairs of the system’s blocks are 
simulated and stored. ETARA does not determine the system capacity states (and state 
availabilities). This selection is intended for use in illustrating a system’s demand for 
maintenance on a yearly basis. The same information can be obtained in a longer-running 
availability simulation. However, the maintainability simulation will run faster since it does not 
take time to calculate the system capacity states. 

While performing a simulation, ETARA displays information describing the filename of the 
system being used, the type of simulation being performed, the number of runs completed out of 
the total number of runs, and the estimated time remaining to complete the total number of runs. 
An example for an Availability simulation is given on the following page. The estimated time 
remaining is read from left— to— right in hours:minutes:seconds. In the example, there is an 
estimated 10 minutes and 19 seconds remaining for completion of the 1,000 runs. 


ETARA Simulation in Progress 
filename 
Availability 

4|un.42 out of 1000 completed 
i Estimatedi time remaining: : . : 10: 19 
(X) to exit early 


If the user presses X during a simulation, ETARA will internally assign the maximum number 
of runs parameter to the next run number, thereby ending the simulation at the completion of the 
current run. Analytical results up to this run number can still be obtained from the 
SIMULATION RESULTS ANALYSIS Menu (3.4). 

ETARA will briefly display the “ETARA Simulation Complete” message on the screen when 
the maximum number of runs have been reached or the user exits early, then return to the 
ETARA MAIN MENU. 

The Batch Mode selection from the ’’Simulation Control” menu allows the user to choose a 
number of system files and assign a type of simulation to each file. ETARA will then 
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successively execute each simulation, saving the results as it goes. After B is selected, ETAR A 
displays a list of stored system files below a list of the types of simulations, 


r; Reliability with repair ' ^ 
n: reliability. Ho repair 
m: Maintainability 


§1 

III 


|Rlen$me 1 . •./; i 


The user can choose to run a type of simulation on any system file by entering the appropriate 
letter in the column to the left of the filename. In the example, a Reliability with repair 
simulation was chosen for system filename 1 while an Availability simulation was chosen for 
system filename 2. 

To start the batch run, the user presses [Enter]. ETARA will load the first stored system in the 
queue and perform the corresponding simulation on it. After the simulation ETARA will store 
the result data in a result file with the same name as the system file. ETARA will continue to do 
this until it reaches the end of the system file queue. 

3.4 The SIMULATION RESULTS ANALYSIS Menu 

Keystroke: (A) 


Availability results , • , . , - 
Reliability results 
Maintainability results 
Time check: . ’.y • • : 

File management' : \ 
eXit to main menu : = If- f- ? ;- J = ^ 


The SIMULATION RESULTS ANALYSIS Menu allows the user to view Availability, 
Reliability and Maintainability analytical results from previously completed simulations. The 
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File management selection allows the user to save, re-load, rename and delete results files as 
well as obtain hard copies of the results. The Time check selection displays clock time used to 
complete the simulation. eXit will return the user to the ETARA MAIN MENU (3.1). 

3.4.1 The AVAILABILITY RESULTS ANALYSIS Menu 

keystrokes: (A) (A) 


| AVAIIAJBIUTY RESULTS ANALYSIS | 
System availability 

Block availability 

Continuous state behavior 
: Probability of exceedence 

■■■■■■■ill* Hi 1 


The AVAILABILITY RESULTS ANALYSIS menu presents the user a number of choices of 
analytical results displays obtained from an availability simulation. Selection S allows access 
to system-level availability results displays while selection B displays results for each block or 
block type in the RBD. Selection C will display statistics regarding the system capacity states 
which occurred during the simulation. eXit will return the user to the SIMULATION 
RESULTS ANALYSIS Menu (3.4). 

The System availability and Continuous state behavior displays combine to give a 
comprehensive description of a system’s behavior in terms of availability. Information from 
these two displays include the number and capacity of whatever system operating states 
actually occurred, from 100% down to 0%, the availability of each capacity state, the average 
continuous time that a system operated at a given capacity state, the average number ol 
occurrences of a capacity state, the availability of a capacity state or greater, and the total 
system’s equivalent availability. Also, histograms of the 100% and 0% capacity stale durations 
are available in selection C. 

The Probability of exceedence selection presents the results of the statistical sampling 
performed on the system for either the cumulative or discrete probability of exceedence 

options. 
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3.4.1.1 System Availability Results 

Keystrokes: (A) (A) (S) 


^^f^4^VAILABItl^Y RESULTS 

Tabular results. " ' : 0 - . 

Graphics display • 

jjji |U : . 


System availability results can be displayed either in Tabular or Graphic format. The tabular 
selection is illustrated below. 


Keystrokes: (A) (A) (S) (T) 



1 : ! ‘ •: ijiji : 8$ • : l St 





SYSTEM CAPACITIES AND AVAILABILITIES 

System 

States' j;:;-; 

: Time at 
Each Cap.; 
• State, Yrs 

'Availability 
of Each 
Cgpcity St. 

Availability 
£ of Capacity 'V. ... 
£ or Greater 

'lEquiyaleht 

Availability 

i mo ; : :: 

7.2 

t: '%72' . 

'■ 0172 •' • 


"'f. 75.0 : £y 

1.0 

.10 

0.82 

' .075 : 

3 50.0 

" ' 1.4 

.14 

0.96 

.070 

4 25.0 

0.3 

.03 i 

0.99 

.008 

5 0.0 

o.i • 

■ -01 

1.00 

.V" ..0001;; 

Summation 

lo.ooo 

i.0000 

lilllililillliPii 

.873 

v •jV'- ’ ^ 

. •. . s * •\v ’ 

: 4 v ' •. ■. • • 





In this example, during 10 years of operation, the first column in the display shows that the 
system functioned at five system capacity states: 100%, 75%, 50%, 25%, and 0%. The next 
two columns to the right show the time in years and the percentage of the total time that the 
system functioned at each state, respectively. The percentage of time at a particular state is also 
known as state availability. Alternatively, this implies that at any given time in the system’s 
operation over the ten years, there is a 72% chance of finding itoperating at 100% capacity. The 
fourth column, “Availability of Capacity State or Greater”, is a cumulative sum of state 
availabilities beginning with the 100% state availability and ending with a 1.0 for the last state 
listed. The third entry down the column shows that the system will operate at the 50% level or 
greater 96% of the time. Alternatively in this case, at any given time in the system’s operation 
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over the ten years, there is a 96% chance of finding it operating at 50% or greater capacity. The 
final column shows the equivalent availability calculation. The system’s equivalent 
availability is shown at the bottom of the column under the horizontal line, 87.3% in this case. 
The entry for individual capacity states is an intermediate result obtained by multiplying the 
capacity state (%) by its state availability (%) and dividing by 100. The intermediate results for 
each state are then summed to determine the total system’s equivalent availability. 

Equivalent availability is a single measure of the overall ’’goodness” of a system. It is the ratio 
of the total actual system production over a time period (considering degraded output states due 
to failures) to the total ideal production (i.e. 100% output 100% of the time). Based on the 
previous paragraph, the area under the graph of state availabilities versus the system capacity 
states is equal to the system’s equivalent availability. It can be viewed as a type of weighted 
average system capacity. There are many alternative ways of expressing equivalent 
availability. For example, suppose the system is a power station which can produce 100 MW at 
its 100% state. A system equivalent availability of 87.3% can be obtained either by the power 
station operating as indicated in the earlier illustrated table, or by operating at 87.3% output 
capacity for 100% of the time, or by operating at 100% output capacity for 87.3% of the time 
and at 0% for 12.7% of the time. The same energy is produced over the same time period for 
each of these cases. 

An important point first mentioned in 3.2. 1.1.4 Block Installation Times is repeated here. 
Before all blocks are installed, the system’s maximum capacity will usually be less than 100%. 
In ETARA, availability results are normalized to the maximum possible output capacity during 
a given time period. This means that during the period when blocks are being installed, 
occurrence of the maximum capacity state possible, even though it could be less than the 100% 
ultimately possible, will be bookept under the 100% capacity state. In the results, the 100% 
capacity state availability includes occurrences of any state which was the maximum possible 
state during a given time period. 

The system availability Graphics display is illustrated in figure 2. This display is a graph of 
system Capacity (y-axis) versus Availability (x-axis). The axis have been normalized with 1.0 
corresponding to 100%. This is an “exceedence plot” in that for a given availability, the plot 
shows the capacity that the system operated at, or above. In the figure, for about 90% of the 
time the system will operate at or above 75% capacity. A given state availability can also be 
determined from the plot by looking at the horizontal length of the power capability plateaus. 
Figure 2 shows the 100% capacity state is available about 85% of the time. As described earlier, 
the system equivalent availability, which is about 93% in this case, can be obtained from the 
area under this curve. 
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Keystrokes: (A) (A) (S)(G) 
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Figure 2 - Graph of System Capacity (y-axis) vs. Availability (x-axis) 
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3.4.1.2 Block Availability 

Keystrokes: (A) (A) (B) 


Individual ‘ 
' by Type 
C exit 


At this point, the user can choose between block failure and repair results displayed either by 
Individual blocks or by block Types. The individual block selection displays data for every 
block which appears in the RBD. The information is displayed in tabular form under the header 
illustrated below beginning with block number one and continuing through the largest block 
number. 
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Keystrokes: (A) (A) (B) (I) 
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After the block name and number are displayed, the total number of failures that the block 
experienced throughout the duration of every run is listed under the “Raw” heading. The 
number of raw failures divided by the number of simulation runs gives the average number ol 
failures per duration, listed under the “Per Dura” column. The “Downtime” column gives the 
total time that the block was unavailable either while being repaired or waiting for a spare. The 
Raw column lists the total down time, in years, for all simulation runs, while the Per Dura 
column lists the average time down per duration, in days. Also, the average percent of the 
duration that the block was unavailable is listed under the “% Dura” heading. The subheadings 
under the “Delay Time” heading list the total time for all simulations, Raw in years, and average 
time per duration. Per Dura in days, that a block was unavailable and waiting for a spare to be 
supplied at the next spares replenishment action. The active repair time can be obtained by 
subtracting the Delay Time from the Down Time. 

The results by block type are displayed under the following heading. 

Keystrokes: (A) (A) (B) (T) 


1 11 "" 1 W.J... ^ : — 


BLOCK TYPE FAILURE AND REPAIR RESULTS 

Block Type 
Name Quant 

# of Failures j Repair Time Per: Percentage Of Total 

Per Dura Year Repair 1 Down 1 Delay 

0tira j Year ; (Days) j (Hours) Time jTirhe. Time 


In this display, results are listed by the different block types. This information is useful in 
determining the relative sensitivities of the different block types with respect to the number of 
failures and repair, delay and total down times. The block type list is ordered from top to bottom 
by decreasing downtime (i.e. the block type at the top of the list spent the most time down 
compared to other block types). The total quantity of blocks of each type are given along with 
the type name. The total number of failures are given per duration (number of total failures 
divided by number of simulation runs) and per year (failures per duration divided by number ol 
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years in a duration). Next, the active repair time for each block type per duration (in days) and 
per year (in hours) is given. The total repair time per year for all block types should be the same 
number as reported for the total yearly maintenance man-hour average in the 
MAINTAINABILITY RESULTS display (see 3.4.3). Finally, each block type’s percent 
contribution to the total repair, down, and delay times are displayed. These three columns 
should each sum to 100%. 

3.4.1.3 Continuous State Behavior 

Keystrokes: (A) (A) (C) 


CONTINUOUS STATE BEHAVIOR 
Tabular results 
Histograms - • 


Selection T will bring up a tabular display of every system capacity state which occurred in the 
simulation along with the availabilities of each state, the average continuous time that the 
system occupied that state, and the average number of occurrences of the state. Selection H will 
bring up another menu which allows the user to choose between histogram displays of the 100% 
or 0% capacity continuous state times. 

The following is an illustration of the tabular results display corresponding to the results first 
given in 3. 4.1.1 System Availability Results, 

Keystrokes: (A) (A) (C) (T) 
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On comparing the two displays, it is seen that the first three columns list the same information: 
System Capacity States, Time at Each Capacity State, Yrs, and Availability of Each Capacity 
State. The additional information presented in this display is the Average Continuous State 
Time (in Days) and the Average Number of Occurrences Per Duration in the two columns on 
the right. 

For every simulation run throughout a system’s duration, ETARA keeps a running total of the 
number of occurrences of a particular state. The total number of occurrences divided by the 
number of runs gives the average number of occurrences of the state per duration (rightmost 
column). Dividing the Time at Each Capacity State by the Average Number of Occurrences Per 
Duration results in the arithmetic Average Continuous State Time, given in Days, listed the 
second column from the right. 

The user is presented with the histogram menu on selecting H from the CONTINUOUS STATE 
BEHAVIOR menu, illustrated as follows, 

Keystrokes: (A) (A) (C) (H) 



100 % AND 0 % STATE HISTOGRAMS 


Full (100 %) capacity • ' 

Zero Capacity 

eXit 

mmmm 


On selection of either F or Z, a frequency distribution histogram of the number of occurrences 
of the capacity state which lasted for a particular range of time is displayed along with the 
calculated mean and standard deviation. 
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Keystrokes: (A) (A) (C)(H)(Z) 



During the simulation, ETAR A stores the length of time the system spent in every occurrence of 
the 100% and 0% capacity states. The bins are equal intervals of time (days), the number of 
which is internally calculated by ETARA from the Sturgess rule equation, 


Number of bins = 1+3.3 log n 

where n is the total number of occurrences of the capacity state. The total number of bins and 
the maximum continuous time spent in the capacity state are used to calculate the bin interval. 
The bin interval is indicated on the display by the From and To (Dys) headings. In the example 
above, bin 1 has an interval from 0 to 28 days. The number of occurrences of the 0% state which 
lasted from 0 to 28 days is indicated by the Freq (Frequency), indicated as 1 1 above. The height 
of the bars are drawn accurate relative to one another, but are not to any actual scale. The mean 
and standard deviation of the 0% state occurrences are also given; the mean being 62 days with a 
standard deviation of 42 days in the example. 

The standard deviation results are given as a means of indicating the variation in the mean 
values. However, the user should use caution in Interpreting this information. Before a system 
simulation is performed, there is usually no prior knowledge of the statistical frequency 
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distribution of the 100% and 0% continuous state time intervals. The calculation of the standard 
deviation for these states does not mean that the continuous state time intervals form a normal 
frequency distribution. 


3.4.1.4 Probability of Exceedence 

ETARA automatically selects the type of probability of exceedence display depending on the 
option selected by the user before running the simulation (see 3.2.1.3.3). If the user selected the 
probability of exceeding a capacity profile, then the probability that the system will meet or 
exceed this capacity profile based on the number of simulation runs performed will be 
displayed, in percent. 

Keystrokes: (A) (A) (P) 


f PROFILE^ 


This probability is calculated by the equation: 


PROBABILITY = 


2 Pi * li 

i = 1 

N 

2 * 

i = 1 


where p is the individual probability, based on a number of simulation runs, that the system s 
output capacity will be equal to or greater than a specific capacity level over an interval of time, 
t. N is the number of capacity levels (over corresponding time intervals) within the profile 
defined by the user. 

The alternative probability of exceedence display is used if the user had selected the multiple 
capacity level criterion. ETARA calculates a probability of exceeding each capacity level at 
every point-in-time specified by the user based on the system behavior over a number of 
simulation runs. The results are displayed in a table. 
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The system capacity levels specified by the user are listed vertically along the left side while the 
user-specified time periods are given horizontally in the first row across the top. The 
probability that the system’s capacity will be equal to or greater than a given capacity at a point 
in time is found at the intersection of a given point in time and capacity. In the example, at year 
1.0, there is a 93% probability that the system’s capacity will be equal to or greater than 75%. 
If the table contains more data than can be displayed on one screen, the user can use the left and 
right arrow keys and the [Pg Up] and [Pg Dn] keys to move around the display. 

Press the [Enter] key to exit from either of these displays. 

3.4.2 RELIABILITY RESULTS 

Keystrokes: (A) (R) 


SYSTEM RELIABILITY 


Number Of Simulated : 

Successes Reliability: 

405 ' ' W~ 


The Reliability Results selection displays the numerical results from a reliability simulation 
(see 3.3). The simple format is illustrated above. The number of successful simulation runs and 
the simulated reliability, calculated by dividing the number of successful runs (465) by the total 
number of runs attempted (500, not shown), are displayed. As described in section 3.3, 
ETARA calculates the reliability of a system to operate at or above a user-specified minimum 
capacity as a function of time. A successful run occurs if the system’s capacity remains greater 
than or equal to the user-defined capacity threshold throughout the duration, or life of the 
system simulation. 
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3.4.3 MAINTAINABILITY RESULTS 


Keystrokes: (A) (M) 


MAINTENANCE MAN-HOURS PER YEAR 


Year 

.. . Mean, 

; Std.Dev.* 


•Hours 

Hours : 

•M0 1 

33.08 

"'24.79 


'47.73 ' 

29.00 ' 

IMB11M 

. . ; 44:35 : ' 

23.82 

3 Year^J.;'.'*;^: 

•$^141.72 

i| 


The Maintainability Results selection displays maintenance man-hour results and statistics 
obtained from a maintainability or availability simulation (see 3.3). The display format is a 
vertical listing of the year, from year 1 through the last year of the duration, with the 
corresponding mean maintenance man-hours for that year along with the standard deviation, 
also in hours, from the mean. These statistics are determined from data stored for all simulation 
runs for a particular case. At the bottom of the display, the average maintenance man-hours 
over all years of the duration is given along with the corresponding standard deviation (hours). 
Note that the standard deviation reported at the bottom is not the average of the standard 
deviations reported for the individual years. 

In the example above, the mean maintenance man-hours for year 1 for the number of 
simulations performed is 33.08 hours with a corresponding standard deviation of 24.79 hours. 
The average maintenance man-hours over the three years of the duration is 41.72 hours with a 
corresponding standard deviation of 7.67 hours. 

3.4.4 TIME CHECK 


Keystrokes: (A) (T) 


TIME CHECK 

Computation clock time » 


This selection displays the clock time used to perform the simulations. The simulation depicted 
in the above example took 7 minutes and 13 seconds to complete. 
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3.4.5 The RESULT FILE MANAGEMENT Menu 

Keystrokes: (A) (F) 


Load previously saved result file : . : 
Save the present results 
jpeiele' a; rebuilt 
Rename a result file 
Print the ^ffesent results 
;':;..'.,eX it 


The RESULT FILE MANAGEMENT Menu is used to Load, Save, Rename and Delete 
“Result” files. The Result files contain all the information needed to display Availability 
(3.4.1), Reliability (3.4.2), or Maintainability (3.4.3) results. Since this menu uses the same 
procedures and format to load, save and delete files as described in 3.2.2, for the SYSTEM FILE 
MANAGEMENT Menu, the user is referred to that section for details. 

Selection P will enable the user to get a hard copy of the present results, whether just obtained 
by a simulation or reloaded from a saved Result file. For both Availability and Reliability 
results, the hard copy contains information of the number of blocks in the RBD, the duration, 
number of runs, resupply interval, spares cutoff period and a tabular listing of block data: 
quantity, capacity, MTBF (random), mean life (wearout), MTTR, shape factor, initial ages, 
installation times and number of local and depot spares (see 3.2.1.2). For Availability 
simulations, the hard copy contains the System Availability (3.4.1. 1), Continuous State 
Behavior tabular results (3.4. 1.3) results, and the MAINTAINABILITY RESULTS (3.4.3). 
For Reliability simulations, the RELIABILITY RESULTS (3.4.2) information is printed. 

eXit will return the user to the SIMULATION RESULTS ANALYSIS menu (3.4). 

3.5 EXIT ETARA 

After X is pressed to exit from ETARA, the following prompt will appear, 

Has the system configuration been saved? Y/N 

This prompt exists so that the user does not inadvertently leave ETARA without saving a newly 
defined system in a System Configuration file. On responding with an N, ETARA returns to the 
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Main Menu, at which the user should select S and F to arrive at the SYSTEM FILE 
MANAGEMENT menu (3.2.2), using selection S to save the system information. 

If the user desires to leave ETARA without saving the system, or the system has already been 
saved, pressing Yat the prompt will terminate ETARA execution. 

4.0 ETARA Algorithm Background 

The intent of this section is to give more detailed descriptions of some of ETARA’s features. 


4.1 Event Simulation 

ETARA is a “next event” driven simulation. The next event is either a block becoming 
available (up) or unavailable (down). A block is the lowest level of division in an RBD and may 
represent hardware, software, or anything else which has reliability and maintainability 
characteristics. Each time a block changes its status it could have an affect on the output 
capacity of the entire system. At every event, the new status of the block, the time that the block 
had existed in its previous state, the new system status, and the time the system had existed in its 
previous state are all recorded. 

To illustrate the next event simulation, a simple block diagram will be analyzed over a small 
period of time. The RBD in Figure 1 will be used as the system. For ease of demonstration, each 
block will be assumed to have a capacity of 100%. This implies the system, as well as the 
blocks, will have a binary status, either 100% or 0%. At the beginning of the simulation, all of 
the blocks are assumed to be available and therefore the system is available at the 100% 
capacity state. As described in detail in the next section, the first time of failure for each block is 
computed via a random number generator and either, or both of the exponential or Weibull 
functions. The earliest failure, which is the minimum of all the first time to failures, is the first 
event of the simulation. From figure 3 (next page), block 4 can be seen to have the earliest 
failure at 0.8 years. 

The system clock is then advanced to this event. The time to repair block 4 is computed, 0.7 
years for this example. Since the clock is at 0.8 and the block will not be fixed until 0.7 years 
have transpired, the block will become available when the system clock reaches 1.5 years. 
Also, the new status of the system with block 4 down is found. In this case, the entire system 
went down when block 4 went down. Since the system was up from 0 to 0.8 years, the duration 
of 0.8 is recorded as the time the system was available at 100% capacity. 

Looking at each block for the next event, it is seen that the earliest event is the failure of block 2 
at 1.0 year. The system clock is advanced to 1.0 and the time to repair is computed. Let the time 
to repair be 0.2 years; this is added to 1.0 and defines the next event for block 2. The system was 
down from 0.8 to 1.0 years and is still down, its status is has not changed. 
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Figure 3 - Example of ETARA ’’Next Event” Determination 


The next event occurs when block 2 is repaired; the system clock is advanced to 1.2 years. The 
next time to failure for block 2 is found to be 1.5 years and is added to 1.2. Block 2 was 
unavailable from 1.0 to 1.2 years, an elapsed time of 0.20 years; this is recorded as the time 
block 2 was down. Even though block 2 has been repaired, the system is still down. The next 
event is the repair of block 4 at year 1.5; the system clock is advanced to 1.5. The next time to 
failure for block 4 is computed as 4.6 years and is added to 1.5, giving the 6.1 entry under block 
4. Just as with block 2, the time that it was down is recorded. With block 4 becoming available 
the system has again become available. The system originally became unavailable at 0.8 years 
and the system clock has advanced 0.7 years; this value is recorded as time the system was 
down. 

The simulation continues to operate until the system clock reaches the duration as specified by 
the user. The program always looks for the next event, at which time a block is either failing or 
being repaired. At each event the following information is determined: the new status of the 
block, the time the block had existed in its old status, the new status of the system, and time the 
system had spent in its old status (if its status has changed). Additionally, a running total is kept 
on how many times each block fails and how many times the system has existed in a particular 
output state. 

The number of runs that is specified by the user determines how many times the program 
performs the simulation for the system duration. In each run, ETARA proceeds through the 
event simulation as described. A run can be thought of as forming a time line with events 
marked all along it. Many time lines must be developed so that an accurate statistical average 
may be calculated and the expected operation of the system can be approximated. The more the 
simulation is run, the more statistically significant the results. 
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4.2 Event Time Generation 


The events in an ETARA Monte-Carlo simulation are block failures and repairs. The phrase 
Monte-Carlo refers to the generation of random numbers which is accomplished in ETARA 
with a standard APL2 operator. The block time-to-failure and time-to-repair intervals are 
generated by inserting the random numbers into a statistical distribution function. The result is 
time intervals that are distributed according to a user-defined distribution function which 
approximates the failure and repair characteristics of the block. 

ETARA uses the Weibull reliability distribution function to generate event times. The 
advantage of using the Weibull distribution function is that it can be used to approximate a wide 
variety of failure and repair distributions. In terms previously used in this manual, the equation 
for the Weibull reliability distribution function is 

R = exp{-[(t+location)/scale] sha P c }, 

where t is the time period, and shape, scale, and location denotes the three parameters of the 
Weibull function. The shape and scale factors can be adjusted to modify the form of the 
distribution. Note that when the shape factor is 1, the Weibull distribution reduces to the 
exponential function where the scale factor is equivalent to the MTBF. The location parameter 
is equivalent to the block initial age or failure free period as described in section 3.2.1. 1.3. A 
positive value for this parameter will move the origin of the Weibull reliability curve to the left, 
modeling a block’s initial age prior to the beginning of the simulation. A negative value will 
move the origin to the right, modeling an initial failure free period where a block can not fail 
with respect to the Weibull function (the block could fail via a random failure if a random 
MTBF is specified for use in conjunction with the Weibull parameters modeling wearout). 

It should be pointed out that this definition of the Weibull function may differ slightly than what 
may be found in reliability textbooks. For example, a common definition is as follows; 

R = exp{-(t-location) sha P e /scale}, 


where, 


shapeETARA = shape 
scaleETARA = scalet/s* 13 !* 5 
locationETARA = - location 

In ETARA, the scale factor is calculated internally from the mean life and shape factor. The 
reason for the sign change on the location parameter is to allow the user to enter positive 
numbers for blocks which have experienced initial aging prior to the beginning of the 
simulation. 

The actual generation of event times in ETARA is described as follows. The Weibull reliability 
distribution function is rearranged to give the time period, t, as a function of reliability, R, and 
the shape, scale, and location factors, 


39 


t = (scale x (-ln(R)) 1 / sha P e ) - location 


Reliability, R, is expressed as a fraction between 0 and 1. Uniformly distributed random 
numbers are generated between 0 and 1 and substituted for R in the above equation. The shape, 
scale, and location factors are given by the user or calculated from user input. The result is time 
intervals, t, which fit the statistical distribution function defined by the Weibull shape and scale 
factors. 

It is important to understand that in an ETARA simulation, the location factor is only used to 
modify the time-to -first- failure for those blocks which have initial ages or failure free 
periods. For each subsequent time-to-failure, the location parameter is set to zero. If a block’s 
failure characteristics are being modeled by both an exponential as well as a Weibull 
distribution, a time— to— failure is generated for both distributions. ETARA takes the minimum 
of the two as the block’s next time-to-failure. 


4.3 Collapsing the RBD 

ETARA operates on series/parallel system RBD configurations as explained in section 2.0. 
After each event occurs in a simulation, ETARA “collapses” the RBD composed of many 
blocks, to one block, which has a capacity that represents the state of the system. Generally, two 
simple rules are followed to accomplish this: 

1) Add the capacities of parallel blocks and/or subsystems. 

2) Take the minimum capacity of series blocks and/or subsystems. 

M-of-N parallel subsystems have their own special rules which are described in detail in 
section 3.2. 1.2.1. 

This collapsing process is performed “from the inside out”. That is, the capacity of the 
innermost subsystem is determined first from the general rules mentioned above. This 
effectively reduces the subsystem to a single “block” with a single output capacity. Subsequent 
subsystem capacities are calculated depending on the status of their constituent blocks and/or 
subsystems. Finally, the system RBD can be represented by one “block” operating at the 
resultant output capacity. 

The process described above is repeated for each event, whether it is a block failure or repair, to 
determine the system’s output capability after each event. This process accounts for most of the 
computer time involved in an ETARA simulation. Figure 4 illustrates the steps involved in 
collapsing the RBD of Figure 1. 
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Figure 4 - ’’Collapsing ” the RBD 

For discussion, assume that event 1) in figure 3 has just occurred: block 4 has failed. Collapsing 
the RBD for this event begins with the determination of the status of subsystem 1. Since blocks 
5, 6, and 7 are at 100%, subsystem 1 is reduced to a single block, denoted SI, operating at 100%. 
Next, subsystem 2 is reduced to a single block, S2, at 100% since blocks 8, 9, and 10 are all 
available. Subsystem 3 is a parallel combination of subsystems 1 and 2 and is therefore also at 
100%. Subsystem 4 is at 100%. Finally, the status of subsystem 5, which represents the entire 
system, is determined by finding the minimum of the capacities of blocks 1 and 4 and 
subsystems 3 and 4. Since the precipitating event was the failure of block 4 reducing it to 0 % 
capacity, whereas block 1 and subsystems 3 and 4 are at 100%, the total system capacity due to 
the occurrence of this event is found to be 0%. 


The process described above is repeated for each event, whether it is a block failure or repair, to 
determine the system’s output capability after each event. This process accounts for most of the 
computer time involved in an ETARA simulation. 
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APPENDIX A 

An ETARA Application: “Duplicate Blocks” 


This appendix describes the specific application of ETARA to a problem where a given block 
appeare more than once in a system RBD. In traditional deterministic RBD modeling, this is not 
allowed since the “collapsing” of the RBD will lead to erroneous system reliability and 
availability results. Collapsing an RBD with “duplicate blocks” is possible in ETARA due to 
the fact that ETARA simulates failures and repairs of individual blocks and the way in which 
the subsystem RBD equations are solved. 

Figure 5 depicts a situation where the system RBD contains multiple occurrences of block 4. 



Figure 5 - RBD containing multiple occurrences of block 4 


In this simple example, the interdependencies of blocks 1, 2 and 4 can be modeled without 
multiple occurrences of block 4, as shown in figure 6. 
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Figure 6 - Same system as figure 5 without "duplicate” blocks 

Both figures are equivalent models for the behavior of the same simple 5 block system. All 
blocks have the same data; 100% capacity, MTBF (exponential) of 2 years, and a MTTR of 
2,200 hours. To keep this example simple, a large number of local spares (9999) are defined. 
This has the effect of restraining the block down time to the MTTR of 2,200 hours without 
spares replenishment considerations. 

The deterministic equations for subsystem and system reliability for the RBD of figure 6 using 
standard series/parallel reliability mathematics are, 


Rsi = 2R - R2 


Rs2 = Rsl x R 


Rs3 = R 2 


Rs4 = Rsystem, fig 6 = Rs2 + Rs3 — (Rs2 X Rs3) 

Rsysiem, fig 6 = R-* - 2R4 — R3 + 3R 2 

The “R” in the above equations is the block reliability. The reliability after 1 year is evaluated 
by calculating the block reliability as, 


Rbiock = R = exp[-l/2] = 0.607 
Giving a system reliability after 1 year, 
Rsystem, fig 6 = 0.692 
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Now, deterministic equations for subsystem and system reliability for the RBD of figure 5, 
containing the double occurrence of block 4, assuming standard series/parallel reliability 
mathematics can be written as, 


Rs =Rsl = ^s2 — Rs3 = R 2 


Rs4 = Rsyslem, fig 5 = Rs^ + 3Rs 2 (l — Rs) + 3Rs (1 — Rs) 2 


with a reliability after 1 year, 


Rsyslem, fig 5 = 0.747 


This result shows the error in applying standard series/parallel reliability mathematics (or in 
using software which is based on the standard mathematics) to the RBD of figure 5. Writing the 
equations in this manner fails to recognize that block 4 in subsystem 1 is duplicated in 
subsystem 2, giving the appearance of three redundant paths for system success when there are 
only two, and an overly optimistic 1 year reliability result. 

ETARA can correctly calculate the reliability of the system of figure 5 owing to its simulation 
of individual block failures and sequential collapsing of the system RBD, subsystem by 
subsystem, from the inside out. The RBD of figure 5 was defined in ETARA and 1,000 
simulations of “Reliability with No Repair” were performed over a 1 year duration. The 
resulting simulated reliability was 0.705, which compares closely to the correct deterministic 
calculation of 0.692. 

ETARA can correctly handle multiple block occurrences in an RBD for both availability and 
reliability simulations. In the example discussed above, it would be preferable to use the RBD 
of figure 6 primarily for the sake of clarity and conciseness. However, many real-life situations 
arise where duplication of blocks in an RBD is unavoidable due to functional dependencies, 
cross-strapping of components, and operational redundancy. A good example is the high 
degree of cross-strapping and switching to redundant pathways in a power distribution 
operation. With this capability, ETARA greatly extends the applicability of RBD modeling. 
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APPENDIX B 


The Data Input Full Screen Editor 

This appendix contains instructions for using the data input full screen editors. These 
instructions may be viewed during the editor session by pressing the Help key, [FI]. The help 
window disappears upon pressing [Escape]. The “Function Key” numbering and 
corresponding keystrokes are as follows: . 

Function Kev Number Keystrokes 

FI - F10 [FI] - [F10] 

F11-F20 [Shift]/[F1] - [F10] 

Quit Editing Session 

To quit the editing session without saving the changes you made, press [Escape]. 

Save Editing Session 

To exit the editing session and save these changes, press [Enter]. 

Cursor Movement 

Use the [Tab] key to move the cursor to the right from one column to the next. Use [Shifi]/[Tab] 
to move the cursor left to the previous column. Press the “Large Plus”, [+], key to jump to the 
next line of the table. Press [F5] to jump to the top row of the table. Press [F6] to jump to the 
bottom row of the table. 

Restore Original Data to Screen 

To restore the original contents at the cursor position, press [F3]. Press [Shift]/[F3] to restore 
the entire row. 

Insert a Row 

To insert a row on the screen, place the cursor one line below where the new line is to be located 
and press [F8]. At the prompt, type in the number of rows to be inserted and press the [Enter] 
key. 

Toggle between Replace and Insert Modes 

At the beginning of an edit session, you will be in Replace mode, in which keystrokes will write 
over the previous text. The editor can also operate in Insert mode, in which the keystrokes will 
move existing text to the right. To switch from one mode to the other, press the [Insert] key. 

Mark/Unmark Rows 

To mark rows of the table for copying, moving, deleting or saving, move the cursor to each of 
the desired rows and press [Shift]/[F9]. Each of the rows will be highlighted. Marked 
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(highlighted) rows may be copied, moved or deleted. To unmark a row, move the cursor to that 
row and press [Shift]/[F9]. To mark or unmark all rows, press [Shift]/[F10], 

Delete Rows 

To delete a row, place the cursor on the row to be deleted and press [Shift]/[F8]. If any rows arc 
marked (highlighted), these rows will be deleted. 

Copy Rows 

To copy a row of the table, move the cursor to the row and press [F10]. If any rows are marked 
(highlighted), these rows will be copied. 

Save Rows 

To save rows of the table for later use, mark the rows (see the paragraph above entitled 
Mark/Unmark Rows), press [Shift]/[F6] and enter a name for this group of rows. 

Retrieve Saved Rows 

Rows saved as described above can be retrieved into an editing session by pressing [Shift]/[F5] 
at the cursor and entering a name. 

Discard Saved Rows 

To discard a set of rows, press [Ctrl]/[F6]. 

Print 

To use the printer while in an editor session, press [F2]. The following options will be available 
with a single keystroke: 

[G]’ Go’: Prints any marked rows. If no rows are marked, the entire table will be 
printed. 

[R] Resets line counter to 0. This aligns the printer to the top of the page. 

[L] Advance the printer 1 line. 

[P] Advance the printer 1 page. 
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APPENDIX C 


Hardware and Software Requirements 

ETARA requires the IBM APL2 programming language on a 80386 based microcomputer with 
a 80387 math coprocessor or an 80486 based microcomputer and at least 2 megabytes of 
extended memory. DOS 3.3 or higher is required for the operating system. APL2 for the PC is 
available from: 

IBM Direct 

Phone: 800-IBM-2468 
Part Number 6242936 

ETARA is provided on 5.25 inch, high density floppy diskettes containing the following three 
files: 


etara.atf 

example_.esf 

example_.erf 

The two “example” files can be read from within ETARA and contain the system configuration 
and analytical results from the example given in Appendix X. 

Installation and Execution Instructions 


To install, copy the ETARA workspace, “etara.atf’, to the system APL2 directory, with the 
DOS “copy” command. Next, enter the APL2 system. It should be noted that ETARA requires 
eight auxiliary processors. An example invocation would be: 

apl232 ap2 ap80 aplOO aplOl apl03 apl24 ap206 ap210 

ETARA can now be loaded from its transfer-format file with the command: 

)IN ETARA 

From here, the user may examine or modify any of the ETARA code. To begin execution of 
ETARA, the main function is called by typing: 

ETARA 
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APPENDIX X 


An ETARA Example 


This appendix illustrates how the user would work through the ETARA menus in order to define 
the example system depicted in figure 1. The keystrokes and data which the user must enter are 
illustrated in boldface type in the following example. This appendix should be used in 
conjunction with section 3.0 of this manual which discusses the ETARA menus in detail. 


X 1.0 System Definition 


Generally, two types of information are necessary in defining a system. One is the block data 
and the other is the reliability block diagram (RBD). To define this information in the order in 
which the ETARA menus are set up, the user first enters block data via the BLOCK DATA 
INPUT menu. From the ETARA MAIN MENU, the user selects ’’System definition; Enter or 
modify data; Block data, numbers, initial ages and installation times”; (Keystroke sequence 
S-E-B). At this point, the BLOCK DATA INPUT menu is displayed. 



BLOCK DATA INPUT 


■ . . Data by type • - • 

. : Numbers for each type ; 

: Ages at beginning of simulation 

Installation times 
eXit 



The user must enter data for the first two selections on this menu. If data is not entered for the 
Ages and Installation time selections, ETARA defaults to ’’zero” for both. This means that all 
blocks will be new (zero initial age) and will be installed and active (zero installation time) at 
the beginning of the simulation. On pressing D, the Block Data editor is displayed; 
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The user enters block type data in this editor, illustrated in bold. Note that even though the 
RBD of figure 1 has ten individual blocks, in this example as defined above, there are only four 
types of blocks. When the block type data entries are complete, the user presses [Enter] to save 
the information and leave the editor. ETARA then returns to the BLOCK DATA INPUT menu. 


Working down this menu, the next choice is ’’Numbers for each type”. On pressing N, the Block 
Number editor is displayed; 


Type 


' type t. 

14 

Lti: <yp«2 

t 3 

type 3 

k 5~7 

type 4 

8-10 


The user assigns block numbers to the different block types. In the example, block numbers 1 
and 4 in the RBD are of block type 1; blocks 2 and 3 are of type 2; blocks 5 through 7 are of type 
3; and blocks 8 through 10 are of type 4. When the block number data entries are complete, the 
user presses [Enter] to save the information and leave the editor. ETARA again returns to the 
BLOCK DATA INPUT menu. 

As mentioned, the ’’Ages at the beginning of simulation” selection is optional. If chosen, 
pressing A will bring up an editor in which the user assigns initial ages to individual blocks via 
the block’s number; 


Age. Yrs 

Block Numbers 

I 

1. . 


4 


Here, initial ages of 1 year for block 1 and 3 years for block 4 have been assigned. Since no 
other initial age assignments are made, ETARA defaults to a zero initial age for the remaining 
blocks. The user presses [Enter] to save the information and leave the editor. 
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The final selection, ’’Installation times”, is also optional. Pressing I brings up an editor in which 
the user assigns installation times to individual blocks; 


Install. 
Time. vr. 

| Block Numbers'' : 

,25 



The above input indicates that block 2 will be installed 3 months (year 0.25) after the beginning 
of the simulation. All other blocks will be installed and active at year 0, the beginning of the 
simulation. Reviewing the block data shows that block 2 has a 75% capacity and is part of a 
simple parallel arrangement in subsystem 4. Since block 2 is not present from the beginning of 
the simulation until the end of the third month (year 0.25), subsystem 4 will only be able to 
contribute the 75% capacity of block 3. This means the system’s maximum capacity will only 
be 75% of its total capacity until block 2 is installed and the system is complete. ETARA 
availability results are normalized to the maximum possible output capacity during a given time 
period. Since 75% capacity is the maximum possible during the first three months, ETARA 
bookeeps occurrences of the 75% output state under the 100% category during this period. 
Therefore, the availability results for this example for the 100% state will include those 
occurrences of the 75% state during the first three months. Press [Enter] to save the 
information and leave the editor. This completes the block data input. Pressing X will return 
the user to the DATA INPUT menu. 


DATA INPUT 

Block data, hiimbers, initial ages and installation times 
Reliability block diagram " \ 

Parameters qf tlie simulation 


The user can now move on to the Reliability Block Diagram (RBD) definition. From the 
DATA INPUT menu, the Reliability block diagram selection brings up the RELIABILITY 
BLOCK DIAGRAM MENU screen. The user then selects the Enter reliability block diagram 
choice which brings up the RBD editor; 
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The input data which defines the RBD of figure 1 on page 2 is shown above. Note that 
subsystem 2 is a parallel 2-of-3 binary arrangement in which 2 or more blocks must be 
available for the subsystem to contribute 50% of the total system capacity. If less than 2 blocks 
are available, then subsystem 2 is at 0% capacity. Press [Enter] to save the information and 
leave the editor. Select eXit to return once again to the DATA INPUT menu. 

Now, the example system has been defined in terms of an RBD and block data. The remaining 
selection from the DATA INPUT menu allows the user to define the Parameters of the 
simulation. 


SIMULATiON PMAI^fek^ 
Duration, number of runs, sjfanes resupply 
Minimum capacity for reliability 

Probability of exceedence . : 

exit 


This example will illustrate the definition of an availability simulation with probability of 
exceedence statistics. Selection D brings up the following field editor; 
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Here, the user has stipulated that the system’s behavior over 30 years (duration) will be 
simulated. Ten (number of runs) separate simulations will be performed from which the 
statistical results will be calculated. If no local spares are available, they will be delivered from 
the depot on 90 day intervals, subject to a 30 day cutoff. This means that if a spare block is 
needed 30 days or less from a scheduled delivery, that spare block must wait until the following 
delivery. The depot spare stock will be replenished every year (365 days). [Enter] is pressed to 
save the information, leave the editor and return to the SIMULATION PARAMETERS menu. 

Since the user is defining an availability simulation, the Minimum capacity for reliability 
choice is skipped. After selecting Probability of exceedence from the SIMULATION 
PARAMETERS menu, the user is presented with two further choices. The ’’Multiple capacity 
level data” choice will be illustrated. 


Probability o: 
Time, yrs 

Excieedence Data 
Capacity •. 
j. levels 


0-lffff, 25 


Here, the user has stipulated that in one year increments throughout the 30 year duration, 
ETARA will take a ’’snap shot” of the system and track whether or not the system’s output 
capacity at that point in time exceeds 0, 25, 50, 75 and 100% (0 through 100 in increments of 
25). At the end of the set of 10 runs of 30 years of simulated system behavior, the probability 
that the system’s capacity met or exceeded 0, 25, 50, 75 and 100% capacity at each year through 
the duration will be reported based on information averaged over the 10 runs. [Enter] is pressed 
to save the information, leave the editor and return to the SIMULATION PARAMETERS 
menu. 

At this point, the user has defined the RBD, block data and simulation parameters. The user 
now presses X twice to return to the SYSTEM DEFINITION menu. The ’’File management” 
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choice is selected so that this newly-defined system can be saved in a system configuration file. 
After the file is saved, X is pressed to return to the ETARA MAIN MENU. The user then 
selects ”Run simulation”, followed by ’’Availability” to begin the simulation. 


X 2.0 Results Analysis 


The results illustrated in this section are what is obtained on running an Availability simulation 
using the system as defined in section X 1.0. The 10 availability simulation runs of a 30 year 
duration for the 10 block system illustrated here took 2 minutes and 23 seconds on a DELL 386 
PC at 20 Mhz with a math co-processor. 

To obtain a menu from which the availability results can be displayed, the user selects ’’Analyze 
results” from the ETARA MAIN MENU followed by ’’Availability results” from the 
’’SIMULATION RESULTS ANALYSIS” menu; 


AVAILABILITY RESULTS ANALYSIS 

— y 

System availability 
Block availability 
Continuous state behavior , 

Probability of exceedence . 1 . f|j 

eXit 4- . Ill 


From this menu, the user can select from a variety of availability result displays. Each selection 
is illustrated in the following pages. After viewing each of the results displays, the user presses 
[Enter] and is returned to the above menu. 
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’’System availability”, followed by "Tabular results”; 


System 

Capacity 

States 





SYSTEM CAPACITIES AND AVAILABIUTIES 
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The 100% state results include the occurrence of the 75% state during the first three months of 
the system’s simulation, since it was the maximum output capacity obtainable do to block 2 not 
being installed. 

’’System availability”, followed by ’’Graphics display”; 

CAPACITY vs. AVAILABILITY 
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Figure 2 - Graph of System Capacity (y-axis) vs. Availability (x-axis) 
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’’Block availability”, followed by ’’Individual”; 
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’’Block availability”, followed by ”by Type”; 
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Continuous state behavior”, followed by "Tabular results 


AVERAGE CONTINUOUS STATE TIME FOR EACH CAPACITY 
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Continuous state behavior”, followed by ’’Histograms”, followed by Zero capacity 
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Probability of exceedence results for years 6 through 30 can be viewed by pressing the ’’right 
arrow” key. 

This completes the illustration of availability results for the example under consideration. 
Since an Availability simulation was performed, Maintainability results can also be displayed. 
This is done by selecting ’’Maintainability results” from the ’’SIMULATION RESULTS 
ANALYSIS” menu. The illustration appears on the next page. 
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The results from the availability simulation can be saved via the ’’File management” selection 
from the ’’SIMULATION RESULTS ANALYSIS” menu. 
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